Traditionally, as shown in FIG. 1, conventional credit cards are assigned a “Bank Identification Number” (BIN) by the American Banking Association (ABA), which acts as a US agent of the international standards organization (ISO). The ISO acts as the global custodian of BINs. A BIN identifies a card's issuing financial institution and typically consists of the first 6 digits of a card's number, which full number length is often 16 digits (more or less) as commonly seen on cards such as Visa and MasterCard, etc.
The ‘rails’, or network communications systems, which connect the retail sales environment (merchants) to the card/account institutions (FI's, or issuers) make use of the BIN to route each financial transaction to the appropriate FI/issuer for approval. More specifically, as shown in FIG. 2, when, for example, a card is used for a purchase, a retailer passes a message (including the card number) to a communications network. The network, based on the card's BIN, is able to properly route the message to the appropriate FI/issuer, namely X, Y or Z.
Each FI/issuer associates various features with their cards/accounts, usually assigning those features available to cards within part or all of a range of numbers within a BIN. For example, if the next three digits beyond the first six (BIN) were used to identify a sub-BIN for a given feature set, the allocation of a BIN would look like this for a 16-digit BIN:
--BIN----subBIN----card number----CRC--1234561231234561
This means that for sub-BIN “123”, the issuer has reserved six digits (10 to the 6th power, or 1,000,000 possible) potential card/account numbers, even if only ONE is ever used to implement a given feature set associated with, e.g., sub-BIN 123. As can be readily appreciated, this common practice makes unavailable a significant portion of the BIN for use by other feature combinations, regardless of how many are actually (ever) used. In this example, there could be 1,000 (000-999) sub-BINs, each having between zero and 1 million active cards.
FIG. 3 illustrates a common implementation of an account database in accordance with the prior art. A master database, or table, typically includes fields for BIN, SUB-BIN, account number and CRC or Luhn (which is used to validate and/or verify the accuracy of credit-card numbers, as is well known in the art). A sister table associates features (e.g., features A, B, C, etc.) with respective SUB-BINs. Features might include, the interest rate, the maximum allowable credit, promotions “points” programs, and the like.
If a large number of sub-BINs were anticipated (i.e., many different sets of feature combinations), the percentage of numbers allocated for various feature sets but not actually associated with an active card could easily rise above 80-90%. While this may just seem to be an inefficient but necessary (and historical) nuisance, the number of BINs available internationally is actually limited, and the ISO group responsible for issuing them is actively seeking the return of unused BINs as the supply of available (remaining) unassigned BINs has diminished. Accordingly, a more efficient means of utilizing available number space within the BIN system is desirable.